Today's sophisticated integrated circuit (IC) designs are rapidly evolving and nearly doubling in size with each generation. In fact, complex designs have nearly exceeded 300 million gates. The complexity of modern designs and the increased use of multiple component blocks integrated into a single device, (forming a “system on chip” (SoC)), have made design verification an essential element in the development cycle. Ultimately, this means that design verification is important to every chip designer, system integrator, and application software developer.
Although the use of pre-packaged designs (sometimes referred to as intellectual property (IP) blocks) and high-performance tools both help the design process by shortening design time, they do not diminish the need to verify the design at the system level, which can consume 60 percent to 70 percent of the design cycle. Additionally, the re-use of intellectual property blocks may cause previously undetected problems to arise when the blocks are combined or integrated into a subsequent design, which may actually increase the need to use verification during the design flow.
Designers can implement a number of verification strategies, including software simulation, simulation acceleration, and rapid prototyping. For system-level verification however, hardware emulation remains a favorable choice over other alternatives due to the superior speed, performance, visibility, flexibility, and accuracy it can provide. For example, hardware emulation can test overall system functionality, subsystem integrity, specification errors, block-to-block interfaces, boundary cases, and asynchronous clock domain crossings.
Prior to using a hardware emulator, the hardware design must be converted or “synthesized” into code that can be used to program the hardware emulator's logic elements. Also, the designs interconnections must be mapped into the hardware emulator. Once the design is synthesized and mapped into the hardware emulator, the design can be “tested” by applying stimuli signals to the hardware emulator and capturing the output from the various logic elements of the hardware emulator. This captured output (known as trace data, visibility data, state data, or user visibility data), is collected from the various elements within the hardware emulator, and provided to the user, processing tools, analysis tools, or storage tools where the data can be used to verify and debug the design under test.
In general, when the design is synthesized and the emulator programmed, less than 50% of the logic elements within the emulator will correspond to the states in the design under test. Occasionally, as little as 30% of the emulator's logic elements will correspond to states within the design under test. As a result, typically only 30% to 50% of the flip flops within the emulator are relevant to the verification of the design under test. (The trace data originating from an element within the hardware emulator that corresponds to a state within the design under test will hereafter be referred to as “relevant” trace data. Similarly, the trace data that does not originate from an element within the hardware emulator that corresponds to a state within the design under test is herein referred to as “irrelevant” trace data.)
The specific logic elements within the hardware emulator that correspond to relevant trace data within the design under test change each time the hardware emulator is programmed As a result, the verification engineer does not know beforehand which elements will correspond to relevant trace data within the design under test. In a conventional hardware emulator, the typical solution to this would be to capture the trace data from each logic element within the hardware emulator. After which the irrelevant trace data that was captured would typically be bypassed. Bypassing the irrelevant trace data from the hardware emulator requires additional logic elements to be included in the data capture circuitry. These additional logic elements greatly increases the area needed for the data capture circuitry. Additionally, bypassing trace data creates timing issues. Thus there is a desire to reduce the number of logic elements within a data capture circuit for use in a hardware emulation environment, while still providing for a robust reconfigurable computing environment with which to emulate, verify, and debug a hardware design. Additionally, there is a desire to capture the relevant trace data in a hardware emulator without the need to bypass the irrelevant trace data.